读《Effective Unit Testing》
我们知道，软件的维护成本远远高于其开发成本，因为开发只占软件生命周期中极小的一部分。 软件行业唯一不变的真理就是需求总会发生变更，所以代码在写就之后的数（十）年间，会被反复阅读和修改。这就使得代码的可读性至关重要，生产代码如是，测试代码如是。
测试极其脆弱
代码是天使与魔鬼的结合体，它既极其灵活，也极其脆弱。 灵活是因为近年来，软件能做的事越来越多，大到上天入地，小到生活起居，软件几乎无所不在。 脆弱是因为，极小的改动都能让整个软件系统瞬间崩溃（crash）。 而测试代码也是代码，所以测试也是极其脆弱的。 在我们大量编写自动化测试的时候，也要考虑到测试的这种脆弱性。
重复是万恶之源
我们都知道 DRY 原则。为什么“重复”会成为头号公敌呢？ 每重复一次，就会给理解代码造成多一分阻碍，也会使需求变更时需要修改的地方又多一处，这就增加了 Bug 潜入的机率（因为你可能会漏掉某个地方）。你肯定不希望把你的测试变成维护的恶梦吧。
重复的定义和分类
简单来说，重复就是 copy 代码，或者有多处代码表达的是同一个概念或逻辑。 重复有多种，一种是字面上的重复（硬编码的数据或值）；一种是结构上的重复，在多处代码中出现同样的逻辑，只是操作的数据不同；还有一种叫“语义重复”，代码虽然看起来不一样，但表达的是同一个意思，这种比较难于发现。
消除重复的方法
从显而易见的重复开始入手，因为消除掉一个明显的重复之后，可能会让其它不明显的重复也变得更明显。 通过提取变量，常量或方法可以很容易地消除重复。 对于不那么容易发现的“语义重复”，可以先修改它们，把它们变成“结构重复”，再通过提取变量和方法消除结构重复。
小心过犹不及
有时候消除重复也会过犹不及，对于测试代码，我们的目标是可读性，如果保留一些重复能增加可读性的话，又何乐而不为呢？
参考资料：
- 申健，独立敏捷教练和软件艺匠，天津软件社区组织者，CSM, CSP。南京大学天津校友会常委。桌面游戏和羽毛球爱好者。博客：http://blog.csdn.net/mebusw，新浪微博：@申导。
- 架构设计最佳实践之 Don’t Repeat Yourself
- 参考《重构-改善既有代码的设计》第六章